X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C935FE.276D8572@onstor-exch02.onstor.net>; Fri, 24 Oct 2008 10:30:05 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C935FE.276D8572"
Content-class: urn:content-classes:message
Subject: RE: Lun Label type-5 Functional Spec. for Kegg
Date: Fri, 24 Oct 2008 10:30:05 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0C19CB37@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E038F9140@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Lun Label type-5 Functional Spec. for Kegg
Thread-Index: Ack0pDOGwsjJ1gNkTEyXhNf4IHF7KQAiul2wAAEHxdAAAFt/oAAAU/bAAAMjlBAACggvEAAkeWsQ
References: <BB375AF679D4A34E9CA8DFA650E2B04E0C19C9C2@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E038F9140@onstor-exch02.onstor.net>
From: "Deepak Veliath" <deepak.veliath@onstor.com>
To: "dl-Design Review" <dl-designreview@onstor.com>,
	"dl-Kegg" <dl-Kegg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C935FE.276D8572
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Jim,
	From your responses it would seem that "lun show disk" will not
list the new partitions/extents as separate entities but simply show a
larger sized LUN with the same device_name, is that correct?  And any
new Lun extents can only belong to the volume that the first extent
belongs to?

So when a "volume show VOLNAME" command is invoked, the size displayed
against each LUN will be the sum of the sizes of the extents in use by
the volume on that LUN (even if they are not contiguous)?

When a volume is deleted do we intend to coalesce any LUN extents to
obtain a single extent?  If so will this affect our volume undelete
feature?

Also how will adding new space to a LUN to a free LUN extent that
previously contained a volume, affect our volume undelete feature?

Thank you,
veliath

> Hello Jim,
> *	From reading the spec I understand you are making space appended
> to a physical LUN accessible by exporting them as partitions or as you
> call them, LUN extents.  What would the device IDs for these
> partitions be as displayed by "lun show disk"?
>=20
> 	There are various defined extent (aka volume) types define.
> Thus far, all we really do is give the allocated extent
> 	to a volume.  There are several details to be ironed out before
> multiple extents become extensively used.
> 	That will be an issue for a future functional spec.   Perhaps we
> should talk about future direction on this subject...
>=20
> *	From the Figure 10 it would seem there is only a single owner
> block for the whole physical LUN.  Does this mean that only a single
> node in a cluster can access the partitions at any given time.
>=20
> 	The idea is to provide a well-known location for the owner block
> so outcluster access can be controlled as well as
> 	Limiting access by other nodes in the cluster.
>=20
> *	If a partition has no FS on it, does it make to append space
> added to the physical LUN to be added directly to the partition?
>=20
> 	At this time the last free extent of the LUN would own any
> expanded capacity added to a LUN.  This is the up-side
> 	of variable-size LUN extents.  (The down-side is fragmentation.
> That becomes an issue once multiple extents=20
> 	are being used.)
>=20
> 	 If a volume was already created using the LUN, it would not
> suddenly get the new capacity.  On down the road, auto-grow would be
> updated to allow the volume to grow into the expanded LUN capacity.
> This is fairly straight forward for a single LUN volume.  A bit more
> complicated for a multi-lun volume.   And I would think that customers
> would want a policy knob to control this behavior.
>=20
> *	Regd Solaris disk-labels, AFAIK on an Intel based system Solaris
> creates a PC MBR, allocates the whole disk (skipping the 1st track) to
> a primary partition of type 0x82 and slices that partition up using
> its native partitioning logic which I believe is very similar to the
> BSDs.  So I believe we're safe on x86 systems running Solaris (which
> in turn means Leopards can co-exist with Cougars on the SAN?).
>=20
> Yes, if Sun honors PC MBR labels, then the new type-5 LUNs we can
> co-exist.
>=20
> This new label has lots of headroom for future growth,
> JIm

------_=_NextPart_001_01C935FE.276D8572
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Lun Label type-5 Functional Spec. for Kegg</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Hello Jim,</FONT>
<UL>
<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">From your responses =
it would seem that &quot;lun show disk&quot; will not list the new =
partitions/extents as separate entities but simply show a larger sized =
LUN with the same<I> device_name</I>, is that correct?&nbsp; And any new =
Lun extents can only belong to the volume that the first extent belongs =
to?</FONT></P>
</UL>
<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">So when a =
&quot;volume show VOLNAME&quot; command is invoked, the size displayed =
against each LUN will be the sum of the sizes of the extents in use by =
the volume on that LUN (even if they are not contiguous)?</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">When a volume is =
deleted do we intend to coalesce any LUN extents to obtain a single =
extent?&nbsp; If so will this affect our volume undelete =
feature?</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Also how will =
adding new space to a LUN to a free LUN extent that previously contained =
a volume, affect our volume undelete feature?</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Thank you,</FONT>

<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">veliath</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Verdana">Hello Jim,</FONT>

<UL>
<LI><FONT SIZE=3D2 FACE=3D"Verdana">From reading the spec I understand =
you are making space appended to a physical LUN accessible by exporting =
them as partitions or as you call them, LUN extents.&nbsp; What would =
the device IDs for these partitions be as displayed by &quot;lun show =
disk&quot;?</FONT></LI>
<BR>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">There are various =
defined extent (aka volume) types define.&nbsp; Thus far, all we really =
do is give the allocated extent<BR>
to a volume.&nbsp; There are several details to be ironed out before =
multiple extents become extensively used.<BR>
That will be an issue for a future functional spec.&nbsp;&nbsp; Perhaps =
we should talk about future direction on this subject&#8230;</FONT>
</P>

<LI><FONT SIZE=3D2 FACE=3D"Verdana">From the Figure 10 it would seem =
there is only a single owner block for the whole physical LUN.&nbsp; =
Does this mean that only a single node in a cluster can access the =
partitions at any given time.</FONT></LI>
<BR>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">The idea is to =
provide a well-known location for the owner block so outcluster access =
can be controlled as well as</FONT>

<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Limiting access by =
other nodes in the cluster.</FONT>
</P>

<LI><FONT SIZE=3D2 FACE=3D"Verdana">If a partition has no FS on it, does =
it make to append space added to the physical LUN to be added directly =
to the partition?</FONT></LI>
<BR>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">At this time the last =
free extent of the LUN would own any expanded capacity added to a =
LUN.&nbsp; This is the up-side<BR>
of variable-size LUN extents.&nbsp; (The down-side is =
fragmentation.&nbsp; That becomes an issue once multiple extents<BR>
are being used.)</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">&nbsp;If a volume was =
already created using the LUN, it would not suddenly get the new =
capacity.&nbsp; On down the road, auto-grow would be updated to allow =
the volume to grow into the expanded LUN capacity. This is fairly =
straight forward for a single LUN volume.&nbsp; A bit more complicated =
for a multi-lun volume.&nbsp;&nbsp; And I would think that customers =
would want a policy knob to control this behavior.</FONT></P>

<LI><FONT SIZE=3D2 FACE=3D"Verdana">Regd Solaris disk-labels, AFAIK on =
an Intel based system Solaris creates a PC MBR, allocates the whole disk =
(skipping the 1st track) to a primary partition of type 0x82 and slices =
that partition up using its native partitioning logic which I believe is =
very similar to the BSDs.&nbsp; So I believe we're safe on x86 systems =
running Solaris (which in turn means Leopards can co-exist with Cougars =
on the SAN?).</FONT></LI>
<BR>
</UL>
<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Yes, if Sun honors PC =
MBR labels, then the new type-5 LUNs we can co-exist.</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">This new label has =
lots of headroom for future growth,</FONT>

<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">JIm</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C935FE.276D8572--
